System and method for managing and updating data from a number of sources for a project

ABSTRACT

The disclosure relates to a system and method for managing data from a number of systems. The method comprises: defining a set of objects for the data; defining a set of classes for the data; maintaining a catalog for each instance of the data; in the catalog identifying each instance&#39;s source system and its level of harmonization with other data; applying a set of harmonization rules to identify from the data a group of related data and an owner of the group; identifying differences in instantiations within the group; and initiating update requests to affected systems having the identified differences.

FIELD OF THE DISCLOSURE

The present disclosure relates to a system and method for managing,comparing, reconciling and updating and presenting data from a number ofdifferent sources for a project, in particular managing and reconcilingdata from different systems involved in managing workflow of a project.

BACKGROUND

In a large scale project, such as managing of an oil drill site ormanagement of a large construction project, the project can be splitinto a number of different, but related, tasks. Each task may havedifferent inputs, outputs, deadlines, criteria and lifespans. As such, atask is typically managed by a separate process. Different systems maybe used to manage each task with separate entities responsible for eachtask. An entity may or may not be related to other entities in othertasks. Further, within each task a collection of different sub-systems(even paper-based data) may funnel data to the central management systemfor the task.

Many large corporate environments have information that is duplicatedacross many data sources. There are many solutions available when itcomes to dealing with managing documents, but support for the on-goingreconciliation of data stored in databases is very limited and thetypical solutions require extensive manual synchronization processes oran expensive process of replacement and consolidation.

Frequently, data is applied to two or more tasks during the project(e.g. the target completion date for the project). When a task has“control” or superior rights to the data and the task determines thatthe data has changed, an updated version of the data needs to beprovided to all tasks in the system that use the data. As an example,development and operation and an oil well site has several differenttasks and issues, including: planning and approval (e.g. drill siteapproval, land access management, etc.), drilling and construction,production and regulatory (e.g. energy utility board, environmentalapproval, zoning approval, etc.). Typically, the planning task managesthe processes for obtaining the required land access approvals for aproposed drilling site. After approval(s) are obtained and aftercompletion of construction of the site, the actual production of maydeviate from the original projected date. As such, the originalregulatory approval(s) may (or may not) need to be updated. Similarly,land access rights may (or may not) need to be revisited.

Prior art data management systems do not effectively deal with managingdata from different tasks. Some prior art management systems impose adata monitor with data write capabilities over the systems that theymonitor. While some data write capabilities may be useful in certaincircumstances, providing such capabilities introduce issues withensuring that data management system properly interfaces with andupdates the data of the local system and that the management system hasthe appropriate data privileges to update the data.

SUMMARY

In a first aspect, a method for managing data provided from a pluralityof systems is provided. The method comprises: providing a set of objectsfor data; providing a set of classes for the data; maintaining a catalogwith an entry for each data instance of the data; in the catalog,identifying for each data instance its source system and its level ofharmonization with other data from the plurality of systems; applying aset of harmonization rules to the data to identify a group of relateddata and an owner of the group of data; identifying differences ininstantiations in the group of data; and initiating an update request toan affected system of the plurality of systems having the differences.In the method, the data is accessable by a central data processingsystem which stores a copy of the data and selectively initiates theupdate requests.

The method may further comprise providing a hierarchical schema datamodel to track and map the data.

The method may further comprise establishing one or more workflows toprovide rules and thresholds used to evaluate whether the data has beenharmonized or not.

The method may further comprise: providing a domain model that isassociated with the data that defines classes, properties and the set ofharmonization rules for the schema data model; creating class librariesfor use in the one or more workflows relating to the data; and assessinga level of harmonization following the set of harmonization rules forthe group of data.

The method may further comprise mapping domain objects related to thedomain model by. creating a list of fields that are used by the domainmodel; organizing the list of fields by source tables; loading eachschema source referenced in the list of fields list and instantiating anappropriate schema extraction driver; and queuing data retrievalrequests for processing.

The method may further comprise: determining whether or not to apply theset of harmonization rule to incoming data based on an evaluation of anintegrity level for the incoming data; processing the data through theone or more workflows to determine whether the data has been harmonizedor not; and generating a list of values from the data that have beenidentified as being acceptable by the one or more workflows.

In the method, the catalog may have a disposition field tracking thelevel of harmonization for the group of data.

In the method, the domain model may have a property field linked to aproperty object; and the level of harmonization may be determined from acomparison of a value for a property field for the data againstproperties of a property object associated with the property field.

The method may further comprise: after processing the data through theone or more workflows updating a copy of the data; and determiningwhether a value for the data is valid. The copy of the data may or maynot be a local copy. The method may or may not update source of the datausing an alias if the source of the data cannot be updated.

The method may further comprise: when the level of harmonizationindicates that the data requires an update, initiating from a workflow arequest to correct the data in the affected system, where the workflowis associated with domain classes and instances of domain classes.

The method may further comprise upon receipt of data from the pluralityof systems: searching the catalog for an entry of the data; and if amatch is found, then utilizing the set of harmonization rules todetermine whether the entry should be replaced with the data, thenreplacing the entry with the updated data and selectively broadcastingthe data to the plurality of systems.

In the method, the workflow may determine at least one of: types ofchanges that are allowed to the data; a threshold for determining alevel of harmony to the data; and whether a fix process can be invokedto harmonize the data.

The method may be executed on a computer system.

In a second aspect, a system for managing data provided from a pluralityof external systems is provided. The system comprises: a microprocessor;memory for storing the data; communication links to the plurality ofexternal systems; a data structure stored in the memory providing a setof classes for the data; a catalog stored in the memory having an entryfor each data instance of the data, the catalog providing anidentification of a source system for each entry and a level ofharmonization with other data from the plurality of systems; and aharmonization module. The harmonization module provides instructionsexecutable on the microprocessor to: apply a set of harmonization rulesto the data to identify a group of related data and an owner of thegroup of data; identifying differences in instantiations in the group ofdata; and initiating an update request to an affected system of theplurality of systems having the differences. In the system, the data isaccessable by the system and the system stores a copy of the data andselectively initiates the update requests.

The system may further comprise a hierarchical schema data model storedin the database to track and map the data.

The system may further comprise one or more workflows providinginstructions executable on the microprocessor defining rules andthresholds used to evaluate whether the data has been harmonized or not.

The system may further comprise: a domain model stored in the memorythat is associated with the data that defines classes, properties andthe set of harmonization rules for the schema data model; and at leastone class library stored in the memory for use in the one or moreworkflows relating to the data. In the system, the harmonization modulemay further assess a level of harmonization following the set ofharmonization rules for the group of data.

The system may further comprise a mapping of domain objects related tothe domain model stored in the memory. The mapping may: have a list offields that are used by the domain model; and organize the list offields by source tables. The harmonization module may further: load eachschema source referenced in the list of fields list and instantiate anappropriate schema extraction driver; and queue data retrieval requestsfor processing.

In the system, the harmonization module may further: determines whetheror not to apply the set of harmonization rule to incoming data based onan evaluation of an integrity level for the incoming data; process thedata through the one or more workflows to determine whether the data hasbeen harmonized or not; and generate a list of values from the data thathave been identified as being acceptable by the one or more workflows.

In the system, the harmonization module may comprise: a first harmonizerapplied to the domain model to determine assignment of new data fieldvalues to domain objects; and a second harmonizer to process changes todata. The first harmonizer may be a factory harmonizer. The secondharmonizer may be a model harmonizer.

In other aspects various combinations of sets and subsets of the aboveaspects are provided.

BRIEF DESCRIPTION OF DRAWINGS

An embodiment of as provided in this disclosure will now be described byway of example only with reference to the accompanying drawings inwhich:

FIG. 1 is a schematic representation of components of a data managementsystem according to an embodiment;

FIG. 2 a is a flow chart of a schema discovery/extraction process usedin the data management system of FIG. 1;

FIG. 2 b is a schematic representation of an exemplary template of aschema data structure used in the data management system of FIG. 1;

FIG. 3 a is a flow chart of a domain modelling process used in the datamanagement system of FIG. 1;

FIG. 3 b is a schematic representation of an exemplary template of adomain model data structure used in the data management system of FIG.1;

FIG. 4 is a schematic representation of an exemplary harmonizer templateof a domain model data structure used by the data management system ofFIG. 1;

FIG. 5 a is a flow chart of a data extraction process used by the datamanagement system of FIG. 1;

FIG. 5 b is a schematic representation of an exemplary extraction queuedata structure used by the data extraction process of FIG. 5 a;

FIG. 6 a is a flow chart of mapping process to map domain objects usedby the data management system of FIG. 1;

FIG. 6 b is a flow chart of another mapping process to map domainobjects used by the data management system of FIG. 1;

FIG. 7 is a schematic representation of an exemplary installation of adata management system of FIG. 1 for an oil drilling site having aseries of operational, data and control tasks providing data on variousaspects of the site;

FIG. 8 is a block diagram of a network connecting the data managementsystem of FIG. 1 for the application of FIG. 7;

FIG. 9 is a flow diagram of a data mapping process used by the datamanagement system of FIG. 1 to categorize processing data received fromthe application of FIG. 8; and

FIG. 10 is a flow diagram of a rule identification process used by thedata management of FIG. 1 to identify distribution rules for data forthe application of FIG. 8.

DESCRIPTION OF EMBODIMENTS

The description which follows, and the embodiments described therein,are provided by way of illustration of an example, or examples, ofparticular embodiments of the principles of the present disclosure.These examples are provided for the purposes of explanation, and notlimitation, of those principles and of the disclosure. In thedescription, which follows, like parts are marked throughout thespecification and the drawings with the same respective referencenumerals.

Briefly, an embodiment provides cross-enterprise integration of data anda flexible data management system and methodology to provide accurate,integrated and scalable use, sharing and updating of data across thesystems in the enterprise.

Referring to FIG. 1, an outline of the main tools of a data managementsystem according to an embodiment are shown. There are four maininter-connected components that are provided/used by an embodiment: i)domain applications, which provide overall management of data systemsfor a defined business model; ii) configuration tools, which providemanagement, maintenance and data definition tools to define data sourcesand models for the system; iii) data collection and management tools;and iv) source data systems. Two external sets of information are usedas part of components i) and iv). For the domain applications, theactual structure of the model for the domain applications is an externaldesign provided to the embodiment. The domain applications codify,maintain and manipulate the model. For the source data systems, eachsystem may maintains local sets of data and copies of sets of data thatare accessed, processed and shared with other components, includingother data systems, through an embodiment. Further detail is providedlater on each of these components.

For the data sources, in an embodiment, a set of workflows rules isdefined and codified to control instantiation of data from the datasources against the model. An initial set of rules may be predefined andamendments to the rules may be implemented using the configurationtools. During instantiation, data is retrieved from the data sources andis applied to the objects for the model. It will be appreciated that aparticular class of data (e.g. “residential address”), may be tracked inseveral data sources (e.g. telephone directory listing, an employer'srecords, etc.). After each object has been instantiated, where there aremultiple instances of a datum, an embodiment arbitrates (or“harmonizes”) among the related data sources to determine a best “owner”(i.e. best source) for the data. As part of harmonizing the datasources, data exploratory probes are provided that can traverse throughassociated their data structure to determine associations of dataelements to properties. As a data model restriction in the embodiment, adata field can be assigned to only one “property” (further detail ondata models for an embodiment are provided later). An embodiment alsoprovides a set of nested data harmonizers that use the structure of thedata model and the associations determined by the probes to identify andcorrect data sourcing and data consistency issues. In an embodiment, astate of data ownership and harmonization for the model is determined bya “property” harmonizer and results from the other harmonizers thatultimately are activated up the hierarchy.

It will be appreciated that when there are multiple instances of datafrom several data sources, there may also be some inconsistencies amongthe instances (e.g. typographical errors, differing formats, etc.). Aspart of the data harmonization, an embodiment assesses multipleinstances of data to attempt to determine a “real” value of the data.Once the real value is determined, it initiates update requests to thesources of the other instances. Also, an embodiment can identify dataentries that are incomplete (when compared to other similar entries ordo not have an associated “owner” and can attempt to resolve suchirregularities or instantiation inconsistencies.

When a data object is “harmonized”, there is deemed confidence in thedata source and the contents thereby providing accurate and reliablereporting of the data throughout the model. However, for the embodiment,it preferably still has only read access to the data. Locally the datasource has its read/write capabilities to modify the data. A local“fix-it” workflow operation may be activated at the data source toupdate the data itself. In one instance, the fix-it workflow may have amanual action by an authorized user provided to implement any datachange, but this requirement can be changed to as needed.

Using the configuration tools, properties of objects can be managed andmodified to add new data sources, create new meta-relationships amongobjects and modify existing properties.

There are four main processes involved in harmonizing data by anembodiment. Each is briefly described in turn.

First, data sources that are relevant to the domain need to beidentified. The sources can include internal and external data sources,including public data. Ultimately, a schema is produced representing amap of the available data sources. The schema is used, in part, tocreate a domain model that will manage harmonization of the datasources. Generally, an initial definition of a domain model begins witha small number of data sources (e.g. less than 10), but the number canbe expanded dynamically over time as the domain model expands.

A review of the data sources can provide a data map providing a machineand source independent map of the data structures accessible by theembodiment. For each element in the map, relevant attributes are alsonoted, such as the data type, access permissions, indices, constraintsand relationships with other data.

The second process defines a domain model. Defining a domain modelconsists of defining a hierarchy of meaningful business objects andtheir relationships, then mapping data fields from one or more schemasto these objects. Part of the model utilizes a hierarchy of constructscalled harmonizers, which are data agents used to map data to objects,assign ownership, and determine whether a state of harmonization for thedata.

The third process assigns data from the data sources to objects in themodel using information relating to the data sources specified in theschemas. When data is first retrieved the domain model uses theharmonizers associated with each domain class to determine whether a newbusiness object needs to be created. If the object already exists thedata is passed to the appropriate existing object. If the data cannot bemapped to a business object an exception processing harmonizer isinvoked to process the data.

For the fourth process, the objects for the model are deployed. Once adata field has been assigned to a new or existing business object astate of harmonization is achieved, where any change to data iscontrolled by its underlying data source, following local datamanagement rules executed at the data source.

Further detail is now provided on each of the four processes.

For the process of identifying data sources, the data management systemof an embodiment needs to be able to access a listed data source andretrieve the target data from it. The data source can be defined interms of its connection parameters, including its related server, thecommunication protocol, the communication port, etc. A GUI interface isprovided by the data management system to allow registration of new datasources for the system. The interface has flexibility to allow new datasources to be added.

The information about the data sources is stored in a local database forthe system. The collective information provides a schema of all the datathat can be accessed by the system for a given model. The connectioninformation for each data element is the root of the schema.

Referring to FIGS. 2 a and 2 b, a discovery process is then executed toretrieve connection information about all data sources. As differentdata sources may utilize different data formats (e.g. SQL, Oracle etc.),an embodiment may need to provide appropriate commands to query thelocal database and extract and interpret the results. As such, anembodiment provides an interface “driver” for each type of database. Theinterface converts commands from the system into a local equivalentcommand for the target database server, converts any messages from theserver to standardized messages for the system and converts the outputreceived from the server into a standardized format. A top-level set ofinterfaces is provided on the system to allow it to access the requiredschema information. The schema extractor uses an interface, such as afactory pattern, to provide flexibility in accessing different datatypes and sources. A factory pattern is a design pattern that separatesthe abstract interface that provides the methods used to performextraction from the actual implementation. This allows an embodiment tosupport new types of data sources and it also simplifies the underlyingsoftware that processes the related data. As part of the data processingby an embodiment, the structure used by the system for tracking data maybe an object or table, but may also be captured in a different datastructure to suit the needs of the model.

Referring to FIG. 2 a, first, a user provides parameters to access adata source. Then a new schema source is added to the repository. Next,the connection is verified. If the verification fails then the processreturns to having the user provide the parameters to access a datasource. If the connection is verified, then a connection is made to thedata source and the schema extractor is loaded. Thereafter, the tablesare extracted and for each table the fields are extracted. A series ofsanity checks is conducted for the extracted field. Therein, all of thefields for a data source are first extracted to determine whether anyforeign constraints will be able to reference the related fields acrosstables. A foreign constraint is imposed from a “foreign” source. Forexample, a customer list may have a list of addresses. It is possiblefor different customers (perhaps from the same family) to share the sameaddress. For the data model, it is possible to assign a uniqueidentification tag to addresses and assign that identification (ID) tagas an “AddressID” for each customer at the same address. In the relatedschema data model, a foreign constraint would be used to specify thatthe AddressID in the customer table must reference a valid AddressID inthe related Addresses table. When all the fields are extracted, then theindexes are extracted. Once all tables are extracted, then for eachtable a constraints are extracted. As part of the mapping, a set ofindexes are maintained to map the domain objects and run the models. Theindexes provide unique identifiers for the rows of data extracted intothe system. Once all constraints are extracted for all tables then aschema is committed. This is repeated for all data sources. Once allschemas have been extracted for all data sources then the extraction iscomplete.

Also, the extraction process maps any native data types of a particulardata source to a standardized data type so that the data can beinternally stored and processed by the system. The data type mappingroutines allow custom data types to be introduced either during theinitial extraction process or later, as needed.

Referring to FIG. 2 b, each schema source used by an embodiment isembodied in a set of linked objects, including objects for:

-   -   SchemaSources    -   Tables Fields    -   Indexes    -   Index fields    -   Fields    -   Foreign keys    -   Foreign key field    -   View fields    -   Views

Each object has a series of subobjects within. Each object may berelated or linked to one or more objects in one or more parent:childrelationships (shown as .infin.:“key” relationships or N:1 relationshipswith the “key”ed relationship listed in the objects). Notable objectsinclude the “Indexes”, “Tables”, “Fields” and “SchemaSources” objects.

Each schema source starts with an entry in the SchemaSources object. TheSchemaSources object describes information required to establish aconnection to the database. While not all the parameters may be neededfor every type of data source, at minimum a unique name should bedefined. The provider field identifies the specific data interface“driver” (described later) to use when connecting to the data source.Every instance of a SchemaSource is described in terms of one or moreobjects. Every object may have one or more indexes. If an index existsthat is flagged as a “IsPrimaryKey” index, that index is used touniquely identify each row during the data extraction process. Everyobject may have one or more foreign constraints. Foreign constraintsprovide information that may impact the deployment of automatic updatesto schema sources and the information is stored to assist analysts whomay configure automatic update scripts.

Referring to FIGS. 3 a and 3 b, the domain modelling process may beinitiated after a sufficient number schemas have been extracted by thesystem, for example at least two or more schemas. An extractionthreshold may be set for a given modelling process and may be 1, 2, 3,4, or more etc. schemas. The threshold may be determined by anycombination of numbers of schemas, types and amount of data extracted. Adomain model may begin as an off line definition of a set of modelingrules that will be captured in the system. The rules are used to definehow and what data from the schema is accessed, to provide constructs asto how to interpret and attribute the data, and to arbitrate and addressdata inconsistencies.

The domain model is a data structure comprising a set of linked classes,properties, methods and “harmonizer” parameters. For a given model, itsdata structure may have customized fields linked and defined in a mannerwhich reflects the desired relationships for the elements in the model.The structure follows object-oriented design principles with childobjects being linked to a parent object(s) in an N:1 configuration,where N is greater or equal to 1.

Domain classes are top level constructs of the structure and can inheritattributes from pre-existing classes. Initially, each domain class needsto be assigned at least one property. Domain classes may also be used todefine custom methods and relationships to other classes, which can bedefined to support the running model and to allow harmonizers to accessrelated information during harmonization of the data by an embodiment.Further details on the components of a domain model are provided later.Domain classes are used to define business objects that are of interestto the domain being modeled. In an embodiment, they provide the primarymean of organizing and defining a domain model. Domain classes aredescribed in terms of properties (for example a domain class “Customer”may have properties like “FirstName”, “LastName”, “CustomerNumber”, etc.Properties are defined by one or more Property fields. A Property fieldlinks a specific FieldID (from a SchemaSource) to a Property. Forexample, a “CustomerNumber” property field may be linked to a“CustomerId” field in a “Customers” object. That “CustomerNumber”property field may also be linked to a “CustomerNumber” field in anotherobject, such as a “CustomerHistory” object.

Referring to FIG. 3 a, a modelling process is as follows. First, a newDomainClass is added to the DomainModel. Then, a new DomainProperty isadded to the DomainClass. Then, a Schema Field is added to theDomainProperty. If the Schema Field is already mapped, then aDomainRelation is added to the DomainClass and then new DomainRelationreferences are made to DomainProperty with the original Schema Field. Ifthe Schema Field is not already mapped, then a new DomainField is addedto the DomainProperty. Then, if there are more fields to be added theprocess returns to adding a Schema Field to a DomainProperty. If thereare no more fields to add, then the process proceeds to set up FieldHarmonizers. If there are more properties to be analysed, then theprocess returns to add another new DomainProperty to DomainClass. Ifthere are no more properties, then the process sets up PropertyHarmonizers. Then, if there are more classes, the process returns toadding a DomainClass to DomainModel. Otherwise, the process sets upClass Harmonizers.

Referring to FIG. 3 b, each model used by an embodiment is defined by aseries of linked objects, including:

-   -   Models    -   Classes    -   ClassRelationships    -   Methods    -   MethodParameters    -   Properties    -   PropertyRelationships    -   Property fields    -   Fields    -   Harmonizers

Each object has a series of subobjects within. Each object may berelated or linked to one or more objects in one or more parent:childrelationships (shown as .infin.:“key” relationships or N:1 relationshipswith the “key”ed relationship listed in the objects).

For an embodiment, an important rule of harmonization is that a FieldIDfrom a schema source may only be assigned to exactly one Property field.Referring to FIG. 3 b, the Fields table is provided from the data modelin FIG. 2 b and it has a 1:1 relationship with the Property fieldstable. This helps to prevent introduction of data racing issues.

When a new domain class is defined that need to reference a field thatis already mapped, a PropertyRelationship is created. ThePropertyRelationship is used to indicate that the new domain class usesthe property, but is not the authoritative source of the underlyingdata. For instance a CustomerID may be part of a PurchaseOrder, but thefield is actually defined (and “owned”) by the Customer domain class.

The top level constructs of a domain model are its domain classes.Domain classes may inherit items from pre-existing classes, akin toobjects in object-oriented models. Each domain class is made up of atleast one property. Domain classes may define custom methods andrelationships to other classes.

To maintain data integrity, some restrictions may need to be imposed onsome elements in the model to ensure certain order, such as a clearchain of ownership of data elements in the model. In one embodiment, thefollowing restrictions may be imposed: (1) a schema field can only mapto one property field; (2) a FieldID from a schema source can only bemapped to a single instance of a Property field; and (3) if a domainclass needs to reference a FieldID that is already mapped to a differentdomain class, then a PropertyRelationship is created that refers to theproperty that contains the Property field referencing the desiredFieldID.

Referring to FIG. 4, harmonizers are shown. Data harmonization traversesthe data schema in a logical manner to identify relevant data elements,track, rank and harmonize them. In the embodiment, the traversal is donein a bottom-up manner. Other embodiments may use different traversalalgorithms. The harmonizer objects in the data schema provide thefollowing roles in the harmonization process:

-   -   They separate harmonization workflows from the domain objects,        as a harmonization workflow may impart an unintended effect on a        domain object.    -   They are used to control aspects of the domain model that are        accessed by the harmonization process.    -   They expose user level extensibility features that allow        authorized user to create custom attributes that can be        associated with any harmonizable domain construct (domain class,        property, property field, and any instances thereof). This        provides support for business domain specific features such as        lifecycle management, state related attributes, and custom        properties that may be useful for reporting and analysis        purposes.    -   During the process of assigning schema field values to domain        objects, harmonizers participate in a nomination process that        determines whether to create a new domain object.    -   When changes are detected in schema field values already        associated with domain objects, harmonizers initiate a scoring        function to evaluate the state of harmony of an object.

A harmonizer has a list of properties, data and attributes. It canmodify its associated domain class or the specific instance of thatdomain class. The harmonizer exposes methods that the workflow can useto define and manipulate these additional properties and it may alsoexpose a subset of the attributes of its associated object. In effect, aharmonizer provides a filter to restrict access of the workflow to itspermitted attributes needed for harmonization. The harmonizer also has acontext provider and an attribute factory. The context provider acts asa filter on the object it is associated with to control what a workflowcan access and change. The attribute/property factory is used by theworkflow to add business domain specific attributes and property domainmodel object.

The embodiment implements two types of harmonizers: a first harmonizeris a factory harmonizer; a second harmonizer is a model harmonizer. Afactory harmonizer is used by a domain model to determine the assignmentof new data field values to domain objects. It also is used duringcreation of new business object instances. In an embodiment, use of afactory harmonizer may be restricted for domain modeling objects (domainclasses, properties and property fields). A model harmonizer processeschanges to data that is already associated with a business object. In anembodiment, a runtime harmonizers may be restricted in use. For examplethey may be restricted such that they may only be used with instantiateddomain model entities (domain objects and their associated propertiesand property fields). A harmonizer has an embedded workflow object thatdefines its runtime behaviour. The workflow object may be edited bybusiness users. The workflow object accesses the underlying domain modelthrough generated classes of code that are instantiated once themodeling is completed.

Referring to FIGS. 5 a and 5 b, after schema sources have been mapped tothe domain model, code has been generated and the harmonizers have beenconfigured, data can be extracted from the data sources to begin mappingof domain objects. The data extractor comprises the followingcomponents: driver factory, fields list manager, data extractor factory,extraction manager, factory queue, intake queue, history cache andchange queue. A driver factory loads the specific driver that is used toestablish a connection to the data source specified by the datasourcefield of the schema source. A fields list manager maintains a list ofthe fields that are mapped to property fields in domain models andconstructs a list of fields to be retrieved from each table in a schemasource. A Data Extractor Factory loads the module that implements theabstract data extraction interface so that the data is extracted fromthe specified schema source. An extraction uses the driver factory andthe data extractor factory to manage data extraction of the fieldsdefined by the fields list manager. The extraction manager operates on aschedule defined by the system administrator for the data managementsystem of an embodiment.

When a new data field is retrieved that is not assigned to a specificinstance of a property field it is added to the factory queue forprocessing. In an embodiment, the factory queue is a first in I firstout (FIFO) buffer. The data is processed by the property fieldIDassociated with the SchemaSourceFieldID specified in the queue.

The embodiment also maintains a history cache. Once a data value hasbeen processed by the property field and the data is associated with arunning instance of domain class (through a “Property” of that classthat contains the property field) the history cache record is updated tohave the DestinationID reflect the identification of the Property fieldinstance).

An embodiment also has an intake queue, which is used by an extractionmanager. All of the data received by an extraction manager is placed inthe intake queue. The data is in the intake queue is processed in twosteps. First, the extraction manager provide additional tagginginformation to the data, including a retrieval date, a data type (asprovided in the “Field” entry of the schema source), a value (taken fromthe schema source), and a source field ID (as provided from the fieldslist). A disposition field is used to indicate the status of theprocessing of the data. Initially, the disposition field is set to“RAW”, indicating that the record is unprocessed. Also, the destinationidentification field is set to NULL. The second step examines eachentry's source field identification in the history cache. If no entry isfound, then: i) the data's disposition is changed to NEW; ii) the recordis moved to the factory queue; iii) a copy is added to the historycache; and iv) the record in the intake queue is deleted. If an entry isfound, then the value of the entry is compared to the record in thehistory cache. If the record is found to be unchanged, then the historyrecord retrieval date is updated and the record in the intake queue isdeleted. However, if the value in the history record differs, then: i)the disposition is changed to CHANGED; ii) the DestinationID is set tothe value in the history cache Record; iii) the record is moved to thechange queue; iv) the history record is updated with the new value alongwith the retrieval date; and v) the intake queue record is deleted. Thisprocessing of data continues until the intake queue is empty.

The history cache contain records that have been retrieved and theirlast dispositions. It is used to decide how to handle records enteringthe intake queue.

A change queue is used to store data that is retrieved that is alreadyassigned to a specific instance of property field. The change queue is aFIFO buffer that holds data for processing by the INSTANCE of theProperty fieldID that is specified in the DestinationID.

The data extractor builds a list of the data fields that are used in amodel and then it extracts the data from the data sources and feeds itto the harmonization process.

One data extraction process comprises the following steps:

1. Create a list of schema fields that are used by domain models usingthe fields list manager.2. Organize the list of fields by source tables and store the list foruse by the extraction manager. This results in a list of fields for eachsource table from which information is to be retrieved. The actualextraction can occurred on a scheduled basis through the extractorfactory or the schema source can be configured to fire an event when newor changed data is available. A data change event triggers step 4 tooccur.3. On predetermined frequency (e.g. based on time or events or acombination of both), the extractor factory accesses the driver factoryto load each schema source referenced in the fields list. Next, then theextractor factory instantiates the appropriate schema extraction driverand queues data retrieval requests for processing.4. New data enters the intake queue for processing. In the embodiment, adata extraction manager triggers the process. The trigger may be ondemand, according to a schedule, or in response to an event triggered byan external event. As described above, the intake queue is compared tothe history cache to determine the appropriate disposition of the data.5. New data elements are moved to the factory queue for processing bythe model factory.6. Data already associated with a domain object that has changed ismoved to the change queue for processing by the model harmonizer.

The steps may be executed in a different order in other embodiments.

The domain model factory processes new data field values and assignsthem to an appropriate domain object. The key goal of the mappingprocess is to assign ownership of every new field value that isretrieved. Field values that have already been assigned to a domainobject are automatically handled by the runtime harmonizers associatedby the object as part of the domain runtime processing described in thenext section.

Referring to FIG. 6 a, the model factory takes data from the factoryqueue and processes the entries as follows. As noted, harmonizationworks from the bottom up in the data schema. As such, data is harmonizedfrom fundamental objects upward. First, the data is checked to seewhether it has a valid targetID. If not, the data element is rejected.The target IDs are defined in the schema source and domain model tables.This is an error state that should not occur unless there was an attemptto process a list of fields intended for a different model.

Next, if the data has a valid targetID, then the property fieldharmonizer may be activated, which then invokes its set of workflowrules. At the property field level, the rules examine the integrity ofthe incoming data to determine if the data is useable. Whether data isuseable or not may depend on parameters of specific business modeldomains. For example, a data may be a field that contains general ledgeraccount codes and its format may determine whether it represents anvalid type of account code. This is a low level process and in mostinstances there may be no determination to be made beyond a simple matchof the datatype (an integer, a Boolean value, etc.). Data that is deemednot useable is queued for later review. If a data instance is rejected,then the property field stores it and makes it available for review bythe data/system administrator through a graphical user interface forviewing all exceptions. The administrator may then determine whichinstance (if any) should own the data and then provide appropriateoverride commands to the system. After the workflow is finished for thatproperty field, its final step is to determine whether or notharmonization should be conducted for that property field. One criteriathat can be used to determine whether or not to harmonize is source ofthe criteria. Other criteria may be used according to the businessmodel. In the embodiment, the domain model has a Property field that hasa harmonizer object. The harmonizer object contains a customizableworkflow that provides codified rules that are applied and analyzed todetermine whether harmonization has been achieved or not. As notedearlier, the harmonizers are nested at different levels. At the level ofa Property field, such workflows can only determine whether the data isreasonable as a value for the Property field. After the analysis of theharmonization at this level, a list of values that have been deemedreasonable for the Property field is generated. In some harmonizationregimes, simple data types may rely on default workflow processing andautomatically accept the values. Each Property field is processed in thesame manner.

Once all property fields are processed, the property class isharmonized. At the property level, the rules organize the groups offield values into recommended sets. Sets that are deemed to beharmonized are passed to the class factory harmonizer. Others are queuedfor review. An analysis of the relationships among the data fields andclasses is conducted to determine how to group fields into therecommended sets and whether a set should be harmonized. At the propertylevel, harmonization may simply be matching the values being proposedfor the Property fields associated with the Property. Processes toimplement such harmonization may be to find the same value in eachProperty fields and line them up. The workflow develop a related set ofrules and processes to identify, assess, and categorize typographicerrors, transcription errors, proximity patterns in the data and others,as appropriate. Preferably, the property ONLY has access to the valuesin the Property fields it owns; the property does not make assessmentsthat would require access to other properties. For example, an ONLYproperty that defines GPS coordinates could be restricted from havingaccess to another property in the same domain class that defineslongitude and latitude.

After the workflow is finished for that property, its final step is todetermine whether the data should be harmonized. Sources and triggersfor criteria to determine whether to harmonize or not are dependent onthe model of the system. A primary goal of harmonization at this levelis to match values from the various Property fields associated with theProperty. For further harmonization, the overall workflow may have arule that a CustomerID needs to exist in every Property field to for theproperty to be considered useable. Alternatively or additionally, theworkflow may deem that as long as the CustomerID value that comes fromthe Customers table is present that is sufficient for harmonization.Each property is processed in the same manner.

Once all properties are processed, the domain class is harmonizedthrough its rules. At the domain class level, the class has access tothe property sets recommended by the property factory harmonizer. Asnoted earlier, when a data element is harmonized, harmonizationrecommendations are generated for its properties and property fieldsthrough its Context object. The workflow determines possibleassociations of property values that would constitute a new instance ofa domain class. Property sets that are deemed to be valid are deemed tobe harmonized for ownership purposes.

A goal of the factory process is to organize sets of data into discreteinstances of a domain class. Once an instance of the domain class hasbeen created, the harmonization process may perform further analysis ofthe data. During the factory process the data has not been assigned toan owner and the workflow is attempting to determine an appropriategrouping of data to create a new instance of a domain class. The newdomain class may then be assigned to an owner. Once an owner is assignedthe harmonization process is triggered, allowing the owner to furtheranalyse the data for its suitability for use for a enterprise businessapplication that consume the information. Sets that are deemed to beharmonized are instantiated as a new domain object. Others are queuedfor review. Again, the harmonizer implements the methods and theworkflow provides the decision that determine how to group fields intothe recommended sets and whether a set should be harmonized. When a newdomain object is instantiated the model harmonizer is triggered to setthe initial internal state of the new domain object. As such, thefactory process only needs to make a decision on ownership, and does notneed to make a complete determination of the internal state of theobject.

Referring to FIG. 6 b, the model harmonizer process processes changesthat occur to data that is already associated with an initialized domainobject. As such a model harmonizer defines and then maintains the stateof harmonization for a domain object that has clearly defined ownership.

The model harmonizer takes data from the change queue and processes theentries as follows. Again, the data is harmonized from the fundamentalobjects upward. So the property field data is harmonized first. Therein,the data is checked to see whether it has a valid target ID. If not, thedata is rejected. Next, if the data has a valid target ID, then theproperty field harmonizer activated which invokes its set of workflowrules.

At the property field level, the rules examine the integrity of theincoming data to determine if the data is useable, as defined by therelated workflow. As part of this process, the harmonizer exposes aSCORE property that is set by the workflow along with a WEIGHT propertythat is controlled by the Class Level Workflow through its harmonizer.These two properties determine the state of harmonization that isultimately controlled by two Boolean properties called HARMONIZED andSTABLE, which are defined at the class level. An instance of a domainclass may not be made available for use outside the data managementsystem of an embodiment until its STABLE property becomes true,indicating that its owner has deemed it to be useable. The HARMONIZEDproperty is set to be true if the owner determines that the classinstance represents an accurate grouping of data. It then compares thenew value to the old value. In most instances, where there is adiscrepancy, the old value is overwritten in the property field.

After the workflow is finished for that property field the locallystored data is updated, either in the alias or fix fields. The owner ofa domain class instance may determine that the value coming from a datasource is invalid. If the underlying data source cannot be updated (forinstance if the source of data comes from an external source thatrefuses to fix the data or if the data comes from an archived sourcethat can no longer be modified), then the owner can update the datathrough an alias. In such a case, the owner can set the alias tooverride the data coming from certain property fields in order toprovide a proper harmonized value.

Where data is deemed to require an update, a workflow of a domain classinstance may initiate a request to fix the data in a source system. Inthe embodiment, fix requests may only be issued by workflows associatedwith domain classes and their instances. Typically, the process offixing the data is external to the embodiment and it could be eitherautomatic or manual. The embodiment tracks a “fixing” status for theexternal data to indicate whether an external fix request has beeninitiated or is in progress. When new data is received and its fixingflag is set (to true), the class level event is sent a FIXCHECK event toallow the workflow to verify whether the requested fix has beenimplemented. The final step is determine whether or not the data for theproperty field is in a sufficient state of harmonization. Each propertyfield is processed in the same manner.

Once all property fields are processed, the property are harmonizedthrough their workflow rules. At the property level, the workflow hasaccess to the property field values. The property needs to determinewhat changes to its property fields impact the state of harmony. Theproperty field may invoke a fix-it process and it may also define analias to override underlying values. The workflow can determine: i) thetypes of changes that are allowed; ii) the thresholds for whether or notthe state of harmony is affected; iii) whether the fix process invokedor not; iv) and other issues. The workflow can also determine whether ornot the data for the property field is in a sufficient state ofharmonization. Each property is processed in the same manner.

It will be appreciated that the embodiment provides a set of datainterface, data entry and reporting GUIs for an administrator of a datamanagement system according to an embodiment allowing a user to define,update and receive reports on the changes and states of the data andtheir sources monitored by an embodiment.

Referring to FIG. 7, further detail of an embodiment is provided throughan example. Therein, data management system 100 according to anembodiment is installed to manage project data associated with oil wellsite 102. Well site 102 has been approved to drill well 104 whichtraverses underground from land parcel 106A (where the well head of site102 is located) westward underneath adjacent land parcel 106B. As isknown in the art, well 104 is comprised of a series of connected casings108A-C. Each casing is connected at a casing point 110. In the field ofoil well production, a universal well identifier (UWI) is an identifiedused to label and track each casing point. As such, a well can berepresented in data by a series of UWIs.

During the lifecycle of an oil well site, different administrative andmanagement tasks will be involved. Different tasks will have differentlifespans. As noted earlier, the tasks may include: planning andapproval, drilling and construction, production and regulatory (e.g.from the EUB), shown as task management systems 112A-D. Data managementsystem 100 is in communication with each task management system 112.Communications can be through wired or wireless connections, using dataencryption and transmission techniques known in the art. An embodimentmanages the flow of data and updates among task management systems 112and system 100.

As an example of management and evaluation of data by an embodiment,consider an example involving planning task system 112A. Therein, itsgoals are to obtain the required land access approvals for a proposeddrilling site. Planning task management system 112A manages andprocesses data functions relating to the task.

In the described data environment where a series of (possibly)interconnected task management systems need to have data consistency forselected data throughout all deemed relevant tasks for a project, anembodiment provides a system and method for managing such data. Forexample, in during the drilling phase, the actual well 104 may deviatefrom the original land access plan and may, in fact, cross under eitheror both or parcels 106C and 106D. This updated information may need tobe reconciled with data from other tasks. A cascading impact may occuron other processes that use the data. For example, the actual locationof well 104 may require new land access rights to be considered byplanning task system 112A. As such, one aspect of an embodiment is thatselected data from task management systems 112 is periodically retrievedby a central management system, such as data management system 100.Initially, a designer identifies the data elements that should beretrieved from a particular task (and its task management system 112),then that data is flagged by the particular task management system 112to be forwarded to data management system 100. The data may be sent on aperiodic basis (e.g. once a day) or on an event basis (e.g. once thewell is in a production stage the availability of specific new datacould trigger an immediate data event). The trigger for sending the datacan vary after certain times or events, depending on the needs of thesystem.

Once the data is received by data management system 100 receives, it canqueue the data or it can process the data immediately (depending onattributes associated with the data). Again, since the designer definedcertain characteristics for the data, the data management system canevaluate the data and react according to (predetermined) conditionsassociated with the data. For example, an instance of the data may bestored in the data management system, when the “owning” task sends anupdated version of the data. The system may compare the updated versionagainst the stored version and determine whether the updated versionshould overwrite some or all aspects of the current version stored inthe system. Also, if an update is executed, then there may be associatedtasks that need to receive some or all of the updated information.Similarly, if a “non-owning” task sends an updated version of the data,then the system may have to evaluate the source of the data anddetermine whether or not to accept some or all of the changes, based onits defined attributes for the data. Each data from each task managementsystem may have different characteristics associated with it, accordingto its own requirements.

Upon a certain condition (either a time or event condition), datamanagement system 100 analyzes the assigned characteristics of the data.For example, the data may be flagged to be distributed to one or moretask system 112. Additionally, the distribution may be controlled bycertain conditions that require evaluation by system 100. Thesecharacteristics and parameters can be set in the overall characteristicsdefined for the data by the designer and codified in software.

Once a condition is satisfied to distribute the data to other tasksystems 112 or other elements in data management system 100, the data ispushed to the receiving system in an appropriate data transmission fromsystem 100. Upon receipt of the pushed data, the receiving task system112 is responsible for identifying from the data its associatedcharacteristics. The task system is then responsible for determiningwhat elements, conditions and data in its local database that need to beupdated. In one embodiment, data management system 100 does not need tohave write access to the local task management system 112. As such,updates can be managed locally. This arrangement provides a simplifiedthe data management system and localized control of the data to theclosest task management system associated with the data.

One feature of an embodiment is that harmonized data is provided for aset of databases that have common data elements therein. This allows forfaster processing of data and can assist in reducing the number of dataelements stored.

Referring to FIGS. 1 and 8, further details are provided on thecomponents, communications and connections related to system 100 andtask management systems 112A-D. System 100 and systems 112A-D areconnected in a network 200. Each system is a microprocessor-basedcomputing platform having local memory storage (not shown), amicroprocessors for executing programs (not shown) and a library ofexecutable programs, algorithms, processes and other modules (not shown)that provide the functionality of the modules, system, components, etc.described herein. Workflows may be embodied into such algorithms. Dataand object structures may be stored in one or more memory storageelements in the system(s). Each system 112 communicates with system 100through communication link 202, which may be a wired or wirelessconnection, per connection systems known in the art. Each system haslocal data storage 204 where it maintains its local data.

Specifically flagged data in storage 204 from any task server 112 can beshared with other systems 112 and system 100 through network 200. Forexample, data that is to be shared from a task system 112A is providedto system 100 through communication link 202. System 200 has dataprocessing module 206 and control module 208. Data processing module 206comprises data communication module 210, (virtual) data repository 212and alias cache 214. Control module has data evaluator module 216 anddata transmission scheduler 218. Each module can send and receivecontrol, status and data to another module (either on the control ordata side) in system 100.

In data processing module 206, data communication module 210 hasprocesses to receive data from links 202 and extract the payloads fromany received data grams. As appropriate, module 210 packages the payloadand provides it to either virtual repository 212 or cache 214. As notedearlier, harmonization process begins with the extraction of schemarelated information (the structure of the tables in the sourcedatabases), which is stored in the data repository. Once a domain modelhas been built the engine retrieves the content of the source databasesbased on the schema elements that are used on domain models. The contentdata is stored in the cache. Data repository 212 is a secondary datastorage system, meant for long term data storage. Cache 214 is providedfor relatively quick access to most recently and/or frequently accesseddata. Cache 214 can access repository 212 and can update contents ofrepository 212, as required. The cache maintains a rolling snapshot thatrepresents the last known state of the data. Individual data elementsmay have a more detailed data retained through rules in the domainmodel. In one embodiment, the cache retains only the most recent valuefor each element. Every time data is retrieved from the data sources thenew data is compared to the previous value and a harmonization event isonly triggered if the new data differs from the cached value. Once datahas been passed to the domain model objects the repository providespersistent storage for the domain objects, including the data resultingfrom the harmonization process.

In control module 208, evaluator 216 has processes selectively extractor review data that is stored in either repository 212 or cache 214 andanalyze its characteristics and associated traits. Depending on theanalysis of the characteristics, with any associated conditions for thedata, the evaluator may cause the data to be: moved from repository 212to cache 214 (or vice versa), selected field(s) to be updated withcertain values (and possibly be written to either or both of repository212 and cache 214) and/or provide the data to scheduler 218 for(eventual) transmission from system 100 to one or more elements innetwork 200 through data communication module 210. Again, a domain modeldefines the domain objects that define the structure of the informationto be harmonized and the rules that process the data. The objects useworkflows to request changes to underlying source systems. Each requestuses a queue to buffer communications.

Referring to FIGS. 1 and 9, further detail is now provided on operationof system 100 in processing data received from one task managementsystem 110 for evaluation and (eventual) distribution one or moretargeted elements in its network. First, in operation, system 100 hasits repository initialized with data and status information for thedata. Process 300 provides a set of rules that will establish an initialload for data management system 100, as executed by control module 208.After a domain model is defined, the instantiation of the model decidesthe domain object that each source data element belongs to. The initialload is used to validate and refine assignment rules that server asinput to a sort of factory process that assemble source data intobusiness objects. First, at step 302, the initial top level objects aredefined. This is a business modeling exercise that defines notable toplevel business abstractions that define the way the business definesitself. This involves a customer modeling tool that allows an analyst toconstruct business objects and associate source data elements with thebusiness objects. Next at step 304, harmonized objects and derivedclasses are generated. This is also referred to as the code generationstep. This is a process of using the domain model defined in 302 andtranslating it into executable code that can dynamically process sourcedata received through the data cache to create instances of the businessdomain objects. In one embodiment, code generation is a useful componentin all future processing and workflows. The generated code—in anembodiment, it may be provided as a series of C# classes—is created toprovide a workflow author an ability to use strong-typed namingconventions workflow rules are built in domain class instances. Forexample a domain name (e.g. “WELL”) may be identified in the workflowmodeling construct using an autocompletion routine such as IntelliSense(trade-mark) from Microsoft corporation. This domain name would enable abusiness or data modeler to start entering the name of the domain model.An autocompletion routine for the embodiment may then begin to fill inall of the under object names and associated child names. At this pointthe business objects typically have only minimal linkage to source datasince all that is required is a single mapping for validation purposes.Next at step 306, the data sources are mapped to attempt to provide afull mapping of source data to business objects. The embodiment uses twokey harmonization design rules here. First, a data field can be mappedto a business object property only once; this implies that in the endall data fields representing the same value should be mapped to singleproperty. This is to ensure a clear ownership and resolutionresponsibility chain. Second, a business object property may be used tocreate a relationship to a property in another object to represent thefact that it utilizes a data element and has (ultimate) ownership ofthat element. The second rule complements the first and it ensures thatdata-rich business objects may express dependencies in the underlyingdata sources. After the data sources are mapped, two parallel step areexecuted: step 308 which updates the catalog and step 310 whichregisters the properties. Step 308 allows the harmony engine to figurewhat data elements should be extracted from source systems. This helpsto ensure that only source data that is actually used in one of thedomain models is extracted. Step 310 allows the harmony engine to knowwhich object properties need to be notified when new data becomesavailable.

Upon completion of steps 308 and 310, the data environment for datamanagement system 100 is established. At this point, a data request canbe received per step 312. Thereafter, the data may be processed forreceipt per step 314. One required data processing feature is theregistration of its properties, so after the data in brought in, acommand is sent to have the data registered, per step 310. In parallel,the final processing step for the data is to queue it to the appropriatequeue in system 100. Again, the data cache retains the last valid valuefor comparison purposes in order to avoid triggering harmonizationevents when no data has actually changed. It will be appreciated that inother embodiments process 300 may be modified in the order of executionof steps, removal or additional of steps.

Referring to FIGS. 1 and 10, further detail is now provided on operationof system 100 in assigning ownership(s) for data and for defining datastates in process 400. Clear ownership is used to resolve datadiscrepancies. A clear chain of ownership makes it possible for rules toraise issues up to a business user with the ability and authority tomake a decision and resolve the issues. As part of this analysis, allparts of a domain model need to indicate their state of harmony; inessence each component has to be able to indicate whether the data thatunderpins it is trustworthy, and to what extent. First, at step 402,property rules for data are defined. As previously noted, in oneembodiment hierarchy harmonizers are used. In one embodiment, everycomponent of a domain model contains exactly one harmonizer. Forexample, each class has one harmonizer; each property of that class hasone harmonizer; and each data field mapped to a property has oneharmonizer. In other embodiments, harmonizers may be omitted for the“property” level. Each harmonizer may provide a workflow and/or astate-machine that control the state of harmony of its associatedentity. Higher level harmonizers are only invoked if the collectivestate of the lower lever harmonizers represent a state deemedtrustworthy by user-defined harmonization rules. As noted above, eachharmonizer can trigger a workflow process to make changes, request achange authorization, and update subscribers on any state change. In anembodiment, since the domain model has been instantiatied as codegenerated c# classes, the harmonizer in the embodiment has easystrongly-typed access to the underlying domain model. This allows thedomain business user to define very complex business rules without theneed to remember the domain model. Next at step 404, the rules arechecked against filters in data management system 100 for harmonizationissues. If the check fails, then the rules are redefined in step 402.Harmonizer objects are responsible for defining what constitutes a statechange and any workflows associated with required changes. Eachharmonizer is limited to consider harmonization in the scope of theobject associated with it. For instance a property harmonizer does notmake any decisions based on the state of the class containing theproperty and it also does not consider harmonization issues affecting asingle data field associated with the property. If the check passes, atstep 406 the object rules for the are defined. Next, at step 408, againthe object rules are checked against filters in data management system100 for harmonization issues. If the check fails, then the rules areredefined in step 406. Finally, if the check passes, at step 410 thecross-object rules for the are defined.

Further features of an embodiment are illustrated through an example ofprocessing of a data from a particular task system 112 to system 100. Inthe example, properties and triggers associated with the data inprovided in Table A. The data may be stored by task system 112,transmitted to data communication module 210, stored by repository 212and cache 214 and evaluated by evaluator 216.

TABLE A Field Value Administrative Details Name these are dependent onthe implementation Location Description Current State/Owner of data TopUWI/Owner of data Bottom UWI/Owner of data Actual Depth/Owner of dataDrill License Number/Owner of data Operator/Owner of dataCoordinates/Owner of data Data Continuity Parameters Broadcast datainformation/ Frequency of broadcast Harmonization State Priority overwhat data? Subordinate to what data? Other data sources

The contents of Table A are transmitted from task system 112 totransmission module 210. After the data is stored in data module 208,its contents are selectively accessed by evaluator 216. Evaluator 216examines selected fields in order to determine when, whether and how tohave the data updated and information about its update transmitted toother elements in network 200.

It will be appreciated that the data management processes and otherapplications in the embodiments can be implemented using knownprogramming techniques, languages and algorithms. Object-oriented dataand program structures may be used to design and implement thecomponents described herein. The titles of the modules are provided as aconvenience to provide labels and assign functions to certain modules.It is not required that each module perform only its functions asdescribed above. As such, specific functionalities for each applicationmay be moved between applications or separated into differentapplications. Different signalling techniques may be used to communicatedata and information between tasks and systems using known programmingtechniques. Data storage, access and update algorithms that allow datato be shared between applications may be used. Local copies of data maybe stored by any of the modules and/or algorithm. Alternatively oradditionally, remote access may be provided to data for a module.

Further, it will be appreciated that other embodiments may be providedto track different types of projects, such as large-scale constructionprojects (e.g. large highway systems, office buildings), largeengineering projects (e.g. dam building, large scale demolitions) andother projects. For a specific environment, a set of tasks and dataelements need to be defined and linked per the implementations describedherein.

As used herein, the wording “and/or” is intended to represent aninclusive-or. That is, “X and/or Y” is intended to mean X or Y or both.Further, in this disclosure, where a dimension is provided as anapproximate value (for example, when the dimension is qualified with theword “about”), a range of values will be understood to be valid for thatrange. For example, for a range stated as an approximate value, a rangeof about 20% larger and 20% smaller than the stated value may be used.Ranges of features are illustrative of embodiments and are not limitingunless noted.

Although the disclosure has been described with reference to certainspecific embodiments, various modifications thereof will be apparent tothose skilled in the art without departing from the scope of thedisclosure as outlined in the claims appended hereto.

1. A method for managing data provided from a plurality of systems,comprising: providing a set of objects for data; providing a set ofclasses for the data; maintaining a catalog with an entry for each datainstance of the data; in the catalog, identifying for each data instanceits source system and its level of harmonization with other data fromthe plurality of systems; applying a set of harmonization rules to thedata to identify a group of related data and an owner of the group ofdata; identifying differences in instantiations in the group of data;and initiating an update request to an affected system of the pluralityof systems having the differences, wherein the data is accessible by acentral data processing system which stores a copy of the data andselectively initiates the update requests.